Day 1 | 遇見 Google ADK 2.0：為何你需要一個企業級 Agent 框架？

主張：agent 上線後失控，通常不是模型不夠聰明，而是把「該不該重試」「該不該相信這個答案」這種程式邏輯層的判斷，全部丟給 LLM 去猜。
讀完能做到：說出 ADK 2.0 要解決的三個生產環境痛點(無窮迴圈、幻覺繞過業務邏輯、例外處理不乾淨)，並理解為什麼這是抽象層級選錯了，不是換個模型就能解決的問題。

一個會無限迴圈的 agent

想像你半年前用一個 agent 框架做出一個退款處理助理：使用者說明退款原因，agent 查訂單、判斷是否符合退款政策、呼叫退款 API、回覆使用者。在 demo 裡它表現得完美無缺——直到它上線的第一週，你在凌晨三點被叫醒，因為它卡在一個迴圈裡，反覆呼叫同一支查詢 API 上百次；隔天你發現它因為誤解了一句含糊的指令，把不符合退款資格的訂單也退了款；再過幾天，一次工具呼叫拋出例外，整個對話流程就這樣悄悄斷在半路，使用者收到的是一個空白回應。

這三個症狀——無窮迴圈、幻覺繞過業務邏輯、例外處理不乾淨——不是某個框架寫得不好，而是 Google 在官方部落格《Why we built ADK 2.0》裡點名的、幾乎所有把 agent 從原型推向生產的團隊都會撞到的牆。這篇文章要談的，正是 Google 為了解決這面牆而打造的框架：Agent Development Kit（ADK），以及它在 2026 年迎來的重大改版 ADK 2.0。

問題不是模型不夠聰明，是抽象層級選錯了

先把問題講清楚。多數 agent 框架的預設做法是：把「接下來該做什麼」這個決策，整個交給 LLM 去想。要不要呼叫工具、呼叫哪一個、呼叫完之後下一步是什麼、出錯了要怎麼辦——這些原本屬於程式邏輯層的判斷，全部被塞進一次又一次的模型呼叫裡。

這聽起來很有彈性，但 Google 官方部落格的論點很直白：把 routing、排程、錯誤處理這些傳統程式碼原本就擅長的工作交給 LLM，雖然做得到，但「slow, expensive, and exhibit variance compared to a workflow or deterministic code」——慢、貴，而且結果不穩定。展開來看，這個選擇會在四個地方持續放血：

Context Bloat & Derailment（上下文膨脹與偏移）。一個自主運作的 agent 會把每一次工具呼叫的冗長輸出，原封不動地堆進對話上下文裡。上下文越滾越大，模型的注意力就越分散，結果是更多不必要的迴圈、更多重複的動作。

Security Vulnerabilities（安全漏洞）。當每一步該做什麼都由 LLM 的推論決定，攻擊面也就跟著模型的推論一起展開——prompt injection 不再只是「讓模型講錯話」，而是有機會真正改變 agent 的執行路徑。

High Token/Latency Costs（不必要的 token 與延遲成本）。一次原本用 if/else 就能解決的路由判斷，如果交給模型去「想」，就是白白燒掉一次 API 呼叫的時間與費用。

Rigid Static Workflows（僵化的靜態流程）。這是另一個極端：如果團隊為了穩定性，退回去寫死一套固定流程，又會失去處理真實世界裡那些複雜、動態業務邏輯的彈性。

ADK 2.0 想解決的，正是這個「全交給 LLM」與「全寫死流程」之間的兩難。它的解法不是選邊站，而是把兩者明確分工：確定性的部分（路由判斷、格式轉換、呼叫外部系統）用程式碼跑，只有真正需要語言理解與推理的部分，才交給 LLM 節點處理。Google 官方對這個設計的定調是：「blend[s] the exploratory capabilities of agents with the strict reliability of deterministic execution logic」——把 agent 的探索能力，跟確定性執行邏輯的嚴格可靠度，融合在一起。

ADK 是什麼：先認識它的核心原語

在談 2.0 之前，先確立 ADK 本身的定位。它是 Google 開源的 code-first agent 開發框架，官方的一句話定位是「Build, Evaluate and Deploy agents, seamlessly」——把建 agent 這件事變得像寫傳統軟體工程一樣有結構、可測試、可佈署，而不是靠反覆調 prompt 硬湊出一個能動的 demo。

ADK 的技術總覽頁列出了幾個貫穿整個框架的核心概念，先建立這張地圖，後面 29 天的內容都會回頭掛在這些原語上：

• Agent：最基本的工作單位。用 AI 模型做推理的是 LlmAgent；不用模型、只做確定性流程控制的叫 workflow agents（SequentialAgent、ParallelAgent、LoopAgent）。
• Tool：讓 agent 具備對話以外的能力，可以呼叫外部 API、搜尋資訊、執行程式碼、呼叫其他服務。
• Callbacks：在 agent 執行過程的特定時點插入自訂程式碼，用來做檢查、記錄或修改行為。
• Session 與 State：Session 管理單一對話的脈絡（含歷史紀錄 Events），State 是這段對話期間 agent 的工作記憶。
• Memory：讓 agent 能跨越多個 session、記得關於使用者的長期資訊，這與只在單一對話內有效的 State 是兩回事。
• Artifact：讓 agent 存取、管理與 session 或使用者關聯的檔案與二進位資料，例如圖片或 PDF。
• Event：session 中發生的每一件事（使用者訊息、agent 回覆、工具呼叫）的基本單位，串起來就是對話歷史。
• Runner：管理整體執行流程、協調 agent 互動、串接後端服務的引擎。

除此之外，官方文件也提到 Multimodal Streaming（即時語音／視訊）、Evaluation（評估）、Deployment（部署）、Debugging 與 Trace 都是這個生態系的一部分——這些正是這個系列後半段（第四篇、第五篇）要處理的主題。

ADK 2.0：從階層式執行器換成圖形化執行引擎

理解了核心原語之後，就能更精準地說出 ADK 2.0 到底改了什麼。官方文件的定義是：ADK 2.0 引入 Workflow Runtime，把 ADK 從一個「階層式 agent executor」，轉型成一個「graph-based execution engine」。

這句話翻成白話：在 2.0 之前，你的 Agent 是一個個獨立的執行單位，彼此透過委派（delegation）或呼叫（as a tool）串起來；在 2.0 之後，你的 Agent、Tool、甚至一段普通的 Function，全部被統一看待成一張執行圖（graph）裡的一個個節點（node）。這不是換個說法而已——它讓你可以像畫流程圖一樣，明確定義資料與控制流怎麼在節點之間傳遞，而不必仰賴 prompt 裡一長串「請依序做 A、然後 B、如果 C 就跳到 D」的自然語言指令。

ADK 2.0 帶來三個彼此互補的招牌功能，這個系列的第三篇（Day 13–20）會逐一深入：

• Graph-based workflows（圖形化工作流）：用宣告式的節點與邊，明確定義任務怎麼被路由與執行，適合需要高度確定性、結構化的流程。
• Dynamic workflows（動態工作流）：用你自己寫的程式碼邏輯（迴圈、條件分支、複雜的決策）來編排，適合控制流太複雜、靜態圖畫不出來的情境。
• Collaborative workflows（協作式工作流）：讓一個 coordinator agent 帶著多個 subagent 一起工作，建構更複雜的多 agent 架構。

跨語言支援藏著這個系列最重要的提醒

ADK 不是一個單一語言的專案，而是五個平行的語言實作：Python、TypeScript、Go、Java、Kotlin。這件事聽起來是加分，但也是這整個 30 天系列裡，最容易讓讀者踩雷的地方，所以放在第一天就要講清楚。

官方文件每一頁的開頭，幾乎都有一行「Supported in ADK Python vX.X.X TypeScript vX.X.X Go vX.X.X ...」——這行字標明了該功能在哪些語言裡存在、從哪一個版本開始存在。而這五種語言的功能覆蓋率差異相當大：

• Graph Workflows（ADK 2.0 的招牌功能）：目前只有 Python 與 Go 支援。
• Agent Routing 與 Cancel Agent Runs：目前只有 TypeScript 支援，而且標記為 Experimental。
• Session Rewind、Session 資料庫遷移、Visual Builder：目前只有 Python 支援。

這意味著，如果你在網路上看到一篇教學示範某個「ADK 的功能」，但沒有標明它是哪個語言、哪個版本，你完全沒辦法確定這件事在你正在用的語言裡能不能用。這個系列接下來的每一篇，只要提到具體 API 或功能，都會標明支援的語言與最低版本——這不是嚴謹癖，而是這個框架現階段真實的狀態。

ADK 接進更大的生態系裡

ADK 不是一個封閉的圍牆花園。對外，它透過兩個開放協定跟世界溝通:面對工具生態,它用 Model Context Protocol（MCP）;面對其他 agent（不論是不是用 ADK 寫的），它用 Agent2Agent（A2A）Protocol。對內,它跟 Google Cloud 的部署平台（Agent Runtime、Cloud Run、GKE）緊密整合,但也刻意設計成可以在容器化環境裡到處跑,不強迫你綁死在單一雲端供應商。模型端也是同樣的開放態度——雖然對 Gemini 系列做了最佳化,但透過 LiteLlm、Apigee AI Gateway 等機制，一樣可以接 Claude、OpenAI、Ollama、vLLM 等其他模型。

這些主題會在系列的第二篇（工具與生態整合）、第三篇（多 agent 協作與 A2A）、第五篇（部署與上線）逐一展開。

接下來 30 天要走的路

這個系列分成五篇、對應五個階段:

1. 新兵入伍（Day 1–5）：核心基礎與開發環境——今天你認識了 ADK 的定位與 2.0 的設計哲學,接下來會實際建立環境、寫出第一個 agent、學會用視覺化工具除錯,以及用 AI 輔助自己的開發流程。
2. 裝備升級（Day 6–12）：工具、記憶與上下文管理——打破 LLM 的能力邊界,讓 agent 具備操作外部世界與記憶的能力。
3. 戰術編排（Day 13–20）：Graph Workflows 與多智能體協作——這是 ADK 2.0 真正的重頭戲,學習怎麼編排複雜邏輯而不讓 AI 失控。
4. 特種作戰（Day 21–25）：即時語音、多模態與環境感知——開發最前沿的串流應用,並處理長時間執行的背景任務。
5. 實彈演習（Day 26–30）：評估、安全監控與企業級上線——把一個原型真正變成能上線、能營運、能被信任的系統。

明天，我們會把這些概念放到一邊，先把手弄髒--建立開發環境，認識 Agents CLI，跑起真正的第一個 agent。